home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-noop-echo-02.txt < prev    next >
Text File  |  1993-04-28  |  25KB  |  663 lines
  1.  
  2.  
  3.  
  4.  
  5.                          An Echo Function for ISO 8473
  6.  
  7.  
  8.           Network Working Group                     IETF-NOOP Working Group
  9.           INTERNET DRAFT                            S. Hares, C. Wittbrodt
  10.  
  11.  
  12.  
  13.  
  14.           1.  Status of this Memo
  15.  
  16.           This memo is an Internet Draft.  Internet Drafts are working
  17.           documents of the Internet Engineering Task Force (IETF), its
  18.           Areas, and its Working Groups.  Note that other  groups  may
  19.           also distribute working documents as Internet Drafts.
  20.  
  21.           Internet Drafts are draft documents valid for a  maximum  of
  22.           six  months.   Internet  Drafts may be updated, replaced, or
  23.           obsoleted by  other  documents  at  any  time.   It  is  not
  24.           appropriate  to use Internet Drafts as reference material or
  25.           to cite them other than as a "working  draft"  or  "work  in
  26.           progress."
  27.  
  28.           Please check the I-D  abstract  listing  contained  in  each
  29.           Internet Draft directory to learn the current status of this
  30.           or any other Internet Draft.
  31.  
  32.           This  Internet  Draft  defines  an  echo  function  for  the
  33.           connection-less  network  layer  protocol.  This memo is not
  34.           intended to compete with an ISO standard.  This  is  a  Pro-
  35.           posed  Elective  Standard for the Internet.  Distribution of
  36.           this memo is unlimited.
  37.  
  38.  
  39.           2.  Abstract
  40.  
  41.           This memo defines an echo function for  the  connection-less
  42.           network layer protocol.  The mechanism that is mandated here
  43.           is in the final process of  being  standardized  by  ISO  as
  44.           "Amendment  X:  Addition of an Echo function to ISO 8473" an
  45.           integral part of Version 2 of ISO 8473.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.           April 13, 1993     Expires October 13, 1993             Page 1
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.                          An Echo Function for ISO 8473
  72.  
  73.  
  74.           3.  Table of Contents
  75.  
  76.           Section 1 Status of this Memo .........................    1
  77.           Section 2 Abstract ....................................    1
  78.           Section 3 Table of Contents ...........................    2
  79.           Section 4 Conventions .................................    2
  80.           Section 5 Introduction ................................    2
  81.           Section 6 The Generic Echo Function ...................    3
  82.           Section 6.1 The Echo-Request ..........................    3
  83.           Section 6.2 The Echo-Reply ............................    4
  84.           Section 7 The Implementation Mechanism ................    4
  85.           Section 7.1 The Echo-Request ..........................    4
  86.           Section 7.2 The Echo-Reply ............................    5
  87.           Section 8 Implementation Notes ........................    5
  88.           Section 8.1 Discarding Packets ........................    5
  89.           Section 8.2 Error Report Flag .........................    5
  90.           Section 8.3 Use of the Lifetime Field .................    5
  91.           Section 8.4 Echo-request function .....................    5
  92.           Section 8.5 Echo-response function ....................    7
  93.           Section 8.6 Use of the Priority Option ................    8
  94.           Section 8.7 Use of the Source Route Option ............    9
  95.           Section 8.8 Transmission of Multiple Echo-Requests ....    9
  96.           Section 9 Security Considerations .....................    9
  97.           Section 10 References .................................   10
  98.  
  99.  
  100.  
  101.           4.  Conventions
  102.  
  103.              The following language conventions are used in the items of
  104.              specification in this document:
  105.  
  106.                 o MUST, SHALL, or MANDATORY -- the item is an absolute
  107.                   requirement of the specification.
  108.  
  109.                 o SHOULD or RECOMMENDED -- the item should generally be followed
  110.                   for all but exceptional circumstances.
  111.  
  112.                 o MAY or OPTIONAL -- the item is truly optional and may be
  113.                   followed or ignored according to the needs of the implementor.
  114.  
  115.  
  116.           5.  Introduction
  117.  
  118.           The OSI Connection-less network layer  protocol  (ISO  8473)
  119.           defines a means for transmitting and relaying data and error
  120.           protocol data units, (PDUs) or preferably,  packets  through
  121.           an  OSI internet.  Unfortunately, the world that these pack-
  122.           ets travel through is imperfect.   Gateways  and  links  may
  123.           fail.   This memo defines an echo function to be used in the
  124.           debugging and testing of the OSI network layer.   Hosts  and
  125.           routers  which support the OSI network layer MUST be able to
  126.           originate an echo packet as well as respond when an echo  is
  127.  
  128.  
  129.           April 13, 1993     Expires October 13, 1993             Page 2
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.                          An Echo Function for ISO 8473
  138.  
  139.  
  140.           received.
  141.  
  142.           Network management protocols can be used  to  determine  the
  143.           state  of a gateway or link.  However, since these protocols
  144.           themselves utilize a protocol  that  may  experience  packet
  145.           loss,  it  cannot  be guaranteed that the network management
  146.           applications can be utilized.  A  simple  mechanism  in  the
  147.           network  layer  is required so that systems can be probed to
  148.           determine if the lowest levels of  the  networking  software
  149.           are  operating correctly.  This mechanism is not intended to
  150.           compete with or replace network management; rather it should
  151.           be  viewed  as an addition to the facilities offered by net-
  152.           work management.
  153.  
  154.           The code-path consideration  requires  that  the  echo  path
  155.           through  a  system  be identical (or very close) to the path
  156.           used by normal data.  An echo path must succeed and fail  in
  157.           unison with the normal data path or else it will not provide
  158.           a useful diagnostic tool.
  159.  
  160.           Previous drafts describing an echo function for CLNP offered
  161.           two  implementation  alternatives  (see  RFC1139).  Although
  162.           backward compatibility is an important  consideration  when-
  163.           ever a change is made to a protocol, it is more important at
  164.           this point that the echo mechanisms  used  on  the  Internet
  165.           interoperate.  For this reason, this memo defines one imple-
  166.           mentation mechanism (consistent with  one  of  the  previous
  167.           drafts).
  168.  
  169.  
  170.           6.  The Generic Echo Function
  171.  
  172.           The following section describes the echo function in a  gen-
  173.           eric  fashion.   This  memo  defines an echo-request entity.
  174.           The function of the echo-request  entity  is  to  accept  an
  175.           incoming  echo-request  packet, perform some processing, and
  176.           generate an echo-response packet.  The  echo  implementation
  177.           may  be  thought of as an entity that coexists with the net-
  178.           work layer.  Subsequent sections will detail the implementa-
  179.           tion mechanism.
  180.  
  181.           For the purposes of this memo, the term "ping" shall be used
  182.           to  mean the act of transmitting an echo-request packet to a
  183.           remote system (with the expectation  that  an  echo-response
  184.           packet will be sent back to the transmitter).
  185.  
  186.  
  187.           6.1.  The Echo-Request
  188.  
  189.           When a system decides to ping  a  remote  system,  an  echo-
  190.           request  is  built.   All  fields  of  the packet header are
  191.           assigned normal values (see implementation specific sections
  192.           for  more  information).   The  address  of the system to be
  193.  
  194.  
  195.           April 13, 1993     Expires October 13, 1993             Page 3
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.                          An Echo Function for ISO 8473
  204.  
  205.  
  206.           pinged is inserted as the  destination  NSAP  address.   The
  207.           rules  of  segmentation  defined for a data (DT) packet also
  208.           apply to the echo-request packet.
  209.  
  210.           The echo-request is switched through the network toward  its
  211.           destination.   Upon  reaching  the  destination  system, the
  212.           packet is processed according to  normal  processing  rules.
  213.           At  the end of the input processing, the echo-request packet
  214.           is delivered to the echo-request entity.
  215.  
  216.           The echo-request entity will build and  dispatch  the  echo-
  217.           response  packet.   This  is  a new packet.  Except as noted
  218.           below, this second packet is built  using  the  normal  con-
  219.           struction  procedures.  The destination address of the echo-
  220.           response packet is taken from  the  source  address  of  the
  221.           echo-request  packet.   Most  options  present  in the echo-
  222.           request packet are copied into the echo-response packet (see
  223.           implementation notes for more information).
  224.  
  225.  
  226.           6.2.  The Echo-Reply
  227.  
  228.           The entire echo-request packet is included in the data  por-
  229.           tion  of  the echo-response packet.  This includes the echo-
  230.           request packet header as well as any data  that  accompanies
  231.           the  echo-request packet.  The entire echo-request packet is
  232.           included in the echo-response so that  fields  such  as  the
  233.           echo-request  lifetime  may  be  examined  when the reply is
  234.           received.  After the echo-response packet is  built,  it  is
  235.           transmitted  toward the new destination (the original source
  236.           of the echo-request).  The rules of segmentation defined for
  237.           a data packet also apply to the echo-response packet.
  238.  
  239.           The echo-response packet  is  relayed  through  the  network
  240.           toward  its  destination.  Upon reaching its destination, it
  241.           is processed by the packet input function and  delivered  to
  242.           the entity that created the echo-request.
  243.  
  244.  
  245.  
  246.           7.  The Implementation Mechanism
  247.  
  248.           The implementation mechanism defines  two  new  8473  packet
  249.           types: ERQ (echo-request) and ERP (echo-response).  With the
  250.           exception of a new type code, these packets will be  identi-
  251.           cal to the date packet in every respect.
  252.  
  253.  
  254.           7.1.  The Echo-Request
  255.  
  256.           The type code for the echo-request packet is decimal 30.
  257.  
  258.  
  259.  
  260.  
  261.           April 13, 1993     Expires October 13, 1993             Page 4
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.                          An Echo Function for ISO 8473
  270.  
  271.  
  272.           7.2.  The Echo-Reply
  273.  
  274.           The type code for the echo-response packet is decimal 31.
  275.  
  276.  
  277.           8.  Implementation Notes
  278.  
  279.           The following notes are an integral part  of  memo.   It  is
  280.           important that implementors take heed of these points.
  281.  
  282.  
  283.           8.1.  Discarding Packets
  284.  
  285.           The rules used for discarding a data packet (ISO  8473,  sec
  286.           6.9  -  sec  6.10) are applied when an echo-request or echo-
  287.           response is discarded.
  288.  
  289.  
  290.           8.2.  Error Report Flag
  291.  
  292.           The error report flag may be set on the echo-request packet,
  293.           the  echo-response  packet,  or both.  If an echo-request is
  294.           discarded, the associated error-report (ER) packet  will  be
  295.           sent  to  the echo-request source address on the originating
  296.           machine.  If an echo-response is discarded,  the  associated
  297.           error-report packet will be sent to the echo-response source
  298.           address.  In general, this will be the  destination  address
  299.           of  the  echo-request  entity.   It should be noted that the
  300.           echo-request entity and the originator of  the  echo-request
  301.           packet are not required to process error-report packets.
  302.  
  303.  
  304.           8.3.  Use of the Lifetime Field
  305.  
  306.           The lifetime field of  the  echo-request  and  echo-response
  307.           packets  should be set to the value normally used for a data
  308.           packet.  Note: although this memo does not prohibit the gen-
  309.           eration  of  a  packet  with  a smaller-than-normal lifetime
  310.           field, this memo explicitly does not  attempt  to  define  a
  311.           mechanism  for  varying  the lifetime field set in the echo-
  312.           response packet.  This memo recommends  the  lifetime  value
  313.           that would under normal circumstances by used when sending a
  314.           data packet.
  315.  
  316.  
  317.           8.4.  Echo-request function
  318.  
  319.           This function is invoked  by  system  management  to  obtain
  320.           information  about  the  dynamic  state of the Network layer
  321.           with respect to (a) the reachability  of  specific  network-
  322.           entities,  and  (b) the characteristics of the path or paths
  323.           that can be created  between  network-entities  through  the
  324.           operation of Network layer routing functions.  When invoked,
  325.  
  326.  
  327.           April 13, 1993     Expires October 13, 1993             Page 5
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.                          An Echo Function for ISO 8473
  336.  
  337.  
  338.           the  echo-request  function  causes  an  echo-request  (ERQ)
  339.           packet to be created.  The echo-request packet shall be con-
  340.           structed and processed by ISO 8473 network-entities  in  end
  341.           systems  and intermediate systems in exactly the same way as
  342.           the data packet, with the following caveats:
  343.  
  344.           a) The information available to the packet composition func-
  345.           tion  (ISO  8473)  consists of current state, local informa-
  346.           tion, and information supplied by system management.
  347.  
  348.           b) The source and destination address fields  of  the  echo-
  349.           request packet shall contain, respectively, a Network entity
  350.           title (NET) of the originating network-entity and a  Network
  351.           entity title of the destination network-entity (which may be
  352.           in either an end system or an intermediate  system).   NOTE:
  353.           A  Network  entity  title is syntactically indistinguishable
  354.           from an NSAP address.  The additional information in an NSAP
  355.           address,  if  any, beyond that which is present in a Network
  356.           entity title, is relevant  only  to  the  operation  of  the
  357.           packet  decomposition  function in a destination end system,
  358.           and therefore is not needed for the processing of  an  echo-
  359.           request  packet (from which no N-UNITDATA indication is ever
  360.           produced).  The fact that the source and destination address
  361.           fields  of  the echo-request packet contain NETs rather than
  362.           NSAP addresses therefore does not affect the  processing  of
  363.           an echo-request packet by any network-entity.
  364.  
  365.           c) When an echo-request packet has reached its  destination,
  366.           as  determined  by the Header processing (call HEADER FORMAT
  367.           Analysis function in ISO 8473), the  echo-response  function
  368.           shall handle this Network Protocol Data Units (NPDU) instead
  369.           of the packet decomposition  function.   In  ISO  8473,  the
  370.           packet  decomposition function is like a decomposing fish on
  371.           the sea shore - it takes a packet down to its bare bones and
  372.           processes it.
  373.  
  374.           Also, it is up to each individual system whether or not han-
  375.           dling echo-request packets involves system management.   One
  376.           example of involving  system  management  is  the  reporting
  377.           reception  of  the  echo packets as some systems do with the
  378.           ping packet.  Some systems find this of value  if  they  are
  379.           being pinged to death.
  380.  
  381.           d) The maximum length of the echo-request packet is equal to
  382.           the  maximum  length  of  the echo-response packet minus the
  383.           maximum length of the  echo-response  packet  header.   This
  384.           ensures that the entire echo-request packet can be contained
  385.           within the data field of the echo-response packet  (see  ISO
  386.           8473).
  387.  
  388.           e) The data part of the echo-request packet may, as a  local
  389.           matter, contain zero or more octets with any values that fit
  390.           within the echo-request packet. (see (d) above for  maximum
  391.  
  392.  
  393.           April 13, 1993     Expires October 13, 1993             Page 6
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.                          An Echo Function for ISO 8473
  402.  
  403.  
  404.           length  of  the  echo-request packet). If the first octet of
  405.           data is binary 1000 0001, then an  echo-response  header  is
  406.           contained in the echo-request packet.  The existence of this
  407.           header insures that a router can formulate a standard  echo-
  408.           response packet.
  409.  
  410.           Normally, the "more segmentation" flag in  the  encapsulated
  411.           echo-response packet header shall be zero, and the segmenta-
  412.           tion  portion  of  the  encapsulated  packet  shall  not  be
  413.           included.   The  segmentation  length  in  the echo-response
  414.           packet header shall be zero.
  415.  
  416.           If the "more segmentation" flag is set in  the  encapsulated
  417.           echo-response  packet  header,  then  a  segmentation length
  418.           shall be filled in and the segmentation part  of  the  echo-
  419.           response  packet header will be present in the echo-response
  420.           header.  This same segmentation function shall be present in
  421.           the echo-response sent by the router.
  422.  
  423.           NOTE: However, this formulated echo-response is not required
  424.           between  any two systems.  With a common format for an echo-
  425.           request packet used in an environment such as the  Internet,
  426.           the  echo-response header may not be needed, and may in fact
  427.           be unnecessary overhead.
  428.  
  429.  
  430.           8.5.  Echo-response function
  431.  
  432.           This function is performed by a network-entity when  it  has
  433.           received  an echo-request packet that has reached its desti-
  434.           nation, as determined by the Header format analysis function
  435.           (ISO 8473 clause 6.3)  that is, an echo-request packet which
  436.           contains, in its destination address field, a Network entity
  437.           title that identifies the network-entity.  When invoked, the
  438.           echo-response function causes an echo-response (ERP)  packet
  439.           to  be  created.   The  echo-response  packet  shall be con-
  440.           structed and processed by ISO 8473 network-entities  in  end
  441.           systems  and intermediate systems in exactly the same way as
  442.           the data packet, with the following caveats:
  443.  
  444.           a) The information available to the packet composition func-
  445.           tion  consists  of  current  state,  local  information, and
  446.           information  contained  in  the  corresponding  echo-request
  447.           packet.
  448.  
  449.           b) The source address  field  of  the  echo-response  packet
  450.           shall  contain the value of the destination address field of
  451.           the  corresponding  echo-request  packet.  The   destination
  452.           address  field of the echo-response packet shall contain the
  453.           value of the  source  address  field  of  the  corresponding
  454.           echo-request packet.
  455.  
  456.           c) The echo-request packet, in its entirety, shall be placed
  457.  
  458.  
  459.           April 13, 1993     Expires October 13, 1993             Page 7
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.                          An Echo Function for ISO 8473
  468.  
  469.  
  470.           into  the  data  part of the echo-response packet.  The data
  471.           part of the echo-response  packet  shall  contain  only  the
  472.           corresponding echo-request packet.
  473.  
  474.           d) If the data part of the echo-request packet  contains  an
  475.           echo-response  header,  the packet composition function may,
  476.           but is not required to, use some or all of  the  information
  477.           contained  therein  to  select  values for the fields of the
  478.           echo-response packet header.  In  this  case,  however,  the
  479.           value  of  the lifetime field contained in the echo-response
  480.           packet header in the echo-request packet data part  must  be
  481.           used as the value of the lifetime field in the echo-response
  482.           packet. The values of the segment length and checksum fields
  483.           shall  be  computed  by the network-entity regardless of the
  484.           contents of those fields in the echo-response packet  header
  485.           in the data part of the echo-request packet.
  486.  
  487.           e) The options part of the echo-response packet may  contain
  488.           any  (or none) of the options described in ISO 8473 (but see
  489.           Section 8.7 of this RFC). The values for these  options,  if
  490.           present,  are  determined  by  the network-entity as a local
  491.           matter.  They may be, but are not  required  to  be,  either
  492.           identical  to  or  derived from the corresponding options in
  493.           the echo-request  packet  and/or  the  echo-response  packet
  494.           header contained in the data part of the echo-request packet
  495.           (if present).   The  source  routing  option  in  the  echo-
  496.           response  packet shall not be identical to (copied from) the
  497.           source routing option in the echo-request packet header.  If
  498.           the recording of route option in the echo-response packet is
  499.           identical to (copied from) the recording of route option  in
  500.           the  echo-request  packet  header,  the  second octet of the
  501.           parameter value field shall be set to the value 3.
  502.  
  503.           f) It is a local  matter  whether  or  not  the  destination
  504.           network-entity  performs the lifetime control function on an
  505.           echo-request  packet  before  performing  the  echo-response
  506.           function.   The  destination  network-entity  shall make the
  507.           same decision in this regard that it would make, as a  local
  508.           matter, for a data packet in accordance with ISO 8473.
  509.  
  510.  
  511.           8.6.  Use of the Priority Option
  512.  
  513.           The 8473 priority function indicates the  relative  priority
  514.           of packet.  0 is normal and 30 is the highest.  Packets with
  515.           higher values will be transmitted before lower values.   The
  516.           specific action upon receiving a 8473 packet with the prior-
  517.           ity field set is a "LOCAL MATTER".   These  means,  any  two
  518.           systems could do it differently.
  519.  
  520.           Hopefully, the future, Internet routers will handle this  as
  521.           a  priority  queueing  function.  Some implementors consider
  522.           the priority queueing function to be a cap.  For example  if
  523.  
  524.  
  525.           April 13, 1993     Expires October 13, 1993             Page 8
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.                          An Echo Function for ISO 8473
  534.  
  535.  
  536.           a  router  is  congested,  all those packets with priorities
  537.           higher than 20, will be  allowed  through,  and  those  with
  538.           priority less than 20 will be dropped.
  539.  
  540.           In short, the basic function of priority has  wide  latitude
  541.           in the ISO specification.  This wide latitude of implementa-
  542.           tion needs to be narrowed for implementations within a  com-
  543.           mon  network  environment  such  as  the Internet.  The 8473
  544.           priority function is rarely implemented in today's Internet.
  545.           The  transmission  of an echo-request packet with a priority
  546.           set may provided unexcepted results until a more wide spread
  547.           deployment  of  the priority feature in 8473 capable routers
  548.           and end systems.
  549.  
  550.           However, if the priority function must be  used  it  is  the
  551.           safest  value  may  be  the value 0 - which indicates Normal
  552.           priority.  It most likely this value will  follow  the  8473
  553.           pathways.
  554.  
  555.           In the future, as the implementation of the  priority  func-
  556.           tion  further  Internet documents will need to deal with its
  557.           expected use.
  558.  
  559.  
  560.  
  561.           8.7.  Use of the Source Route Option
  562.  
  563.           Use of the source route option in ISO 8473 may cause packets
  564.           to loop until their lifetime expires.  For this reason, this
  565.           memo recommends against the use of the source  route  option
  566.           in  either an echo-request or echo-response packets.  If the
  567.           source route option is used to specify the  route  that  the
  568.           echo-request  packet takes toward its destination, this memo
  569.           does not recommend the use  of  an  automatically  generated
  570.           source route on the echo-response packet.
  571.  
  572.  
  573.           8.8.  Transmission of Multiple Echo-Requests
  574.  
  575.           The echo function may be utilized by more than  one  process
  576.           on  any individual machine.  The mechanism by which multiple
  577.           echo-requests and echo-replies are correlated between multi-
  578.           ple  processes on a single machine is a local matter and not
  579.           defined by this memo.
  580.  
  581.  
  582.  
  583.  
  584.           9.  Security Considerations
  585.  
  586.           Security issues are not addressed in this memo.
  587.  
  588.  
  589.  
  590.  
  591.           April 13, 1993     Expires October 13, 1993             Page 9
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.                          An Echo Function for ISO 8473
  600.  
  601.  
  602.           10.  References
  603.  
  604.           [1] ISO/IEC.  Protocol for Providing the Connectionless-mode
  605.           Network  Service.   International Standard 8473, ISO/IEC JTC
  606.           1, Switzerland, 1986.
  607.  
  608.           [2] R. Hagens, "An Echo Function for ISO 8473", Request  For
  609.           Comment    #1139,   January 1990.   DDN Network  Information
  610.           Center, SRI International.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.           April 13, 1993     Expires October 13, 1993            Page 10
  658.  
  659.  
  660.  
  661.  
  662.  
  663.